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Abstract There are numerous technical reviews that occur throughout the systems 
engineering process life cycle. Many are well known by project managers and stakeholders 
such as developers and end users, an example of which is the critical design review (CDR). 
This major milestone for a large, complex new project may last two or more days, include an 
extensive agenda of topics, and entail hundreds of hours of developer time to prepare 
presentation materials and associated documents. Additionally, the weeks of schedule spent 
on review preparation is at least partly at the expense of other work. 

This paper suggests an approach for tailoring technical reviews, based on the project 
characteristics and the project manager’s identification of the key stakeholders and 
understanding of their most important issues and considerations. With this insight the project 
manager can communicate to, manage expectations of, and establish formal agreement with 
the stakeholders as to which reviews, and at what depth, are most appropriate to achieve 
project success. The authors, coming from diverse organizations and backgrounds, have 
drawn on their personal experiences and summarized the best practices of their own 
organizations to create a common framework to provide guidance on the adaptation of design 
reviews to other system engineers. 


Introduction 

Tailoring of systems engineering processes to address the needs and objectives of a specific 
effort is a well-established and accepted practice. For example, the discussion of tailoring in 
(MIL-STD-1521B 1985) considers project complexity by noting: 

“When developing a small non -complex system some reviews may not be 
required, or, if required, may be limited in Scope.... Conversely, in a very 
complex development the review process will increase in levels and number 
of reviews. ...the degree of application is dependent upon the configuration 
item state of development (example, new design vs. commercially available) 
or the degree of any modifications, if involved. For example: a newly 
developed item may require the majority of the review topics/items and audits, 
while a commercially available configuration item with the appropriate 


documentation . . may require reviews or audits limited to its application to the 
project and its interfaces.” 

In addition to the project characteristics, we suggest an approach for tailoring based on 
the project manager identifying the key stakeholders, and then considering their most critical 
issues and considerations. The project manager now has the insight needed to establish, with 
the agreement and commitment of the stakeholders which technical reviews, and at what 
level of detail, are most appropriate. 

In tiiis paper we first identify and briefly describe six major frequently conducted 
technical reviews. We then identify six stakeholders, and propose a set of generic questions 
to guide an assessment erf the primary interests of each. We provide three scenarios, 
developed as composites from the authors’ experience, to illustrate how a project manager 
can use this approach to establish the technical reviews that meet project objectives while 
addressing the most important stakeholder concerns. 

Major Technical Reviews 

This section discusses six frequently conducted technical reviews that represent key 
milestones that occur during the project lifecycle. The information presented here is of a 
general nature to describe the purpose and scope of information reviewed during a project. 
The objective is to provide a common understanding of these reviews to support later 
consideration of various factors that help to guide project manager decisions about 
technical reviews appropriate for a project. The following is based on information containt 
in (MIL-STD-1521B 1985, INCOSE Handbook 2000); for more detailed information the 
reader is directed to any introductory systems engineering text. 

System Requirements Review (SRR) 

Purpose. To confirm that the system technical requirements satisfy the user requirements; 
identify critical technologies; demonstrate that the product development team understands the 
project-level and system-level requirements. 

Likely entry criteria. Preliminary requirements and functional analysis completed; draft 
system specification developed. 

Sample items reviewed. Products of requirements allocation and functional analysis; results 
of trade studies; project risk analysis; life cycle cost analysis; specialty engineering studies. 
Likely exit criteria. Completed draft functional baseline; risk identification and mitigation 
approach defined. 

Definition of success. Fully established and defined understanding of system requirements. 

System Design Review (SDR) 

Purpose. To evaluate the completeness of the technical requirements allocated to the system 
design; examine the application of SE management processes to the system definition. 

Likely entry criteria. System specification requirements defined; performance requirements 
allocated to design. 

Sample items reviewed. System specification; preliminary software requirements 
specification; preliminary interface requirements specification; technical risks. 

Likely exit criteria. All system level requirements allocated to one or more lower levels; 
development verification/test plans created. 



Definition of success. The system is understood enough to warrant design and acquisition of 
the end items. Plans to control and integrate the technical processes are in place. 

Preliminary Design Review (PDR) 

Purpose. To evaluate the technical adequacy of the basic design to meet all specified system 
functions, performance, and interface requirements. 

Likely entry criteria. Hardware development specifications and software design 
documentation are available. 

Sample items reviewed. Preliminary hardware design data; trade studies results; compute- 
software functional flow specifications; human factors studies. 

Likely exit criteria. Operations concept, interface documents, detailed project plans. 
Definition of success. The “design-to” baseline is approved, and the project is authorized to 
proceed to final design. 

Critical Design Review (CDR) 

Purpose. To ensure the detailed design satisfies the performance and engineering specialty 
requirements; to determine readiness of the functional baseline for hardware development 
and software coding. 

Likely entry criteria. Draft hardware product specification and software detailed design 
document are available. 

Sample items reviewed. Hardware product specifications; detailed design of computer 
software configuration items. 

Likely exit criteria. Design is complete and meets all requirements; all internal and external 
interfaces define; system integration and verification plans complete. 

Definition of success. Design baseline production and verification plans are approved. 

Test Readiness Review (TRR) 

Purpose. To determine whether the test procedures are complete and the developer is ready 
to begin formal testing of software and hardware items; ensure that the hardware and 
software, test facility, test support personnel and test. 

Likely entry criteria. Software and hardware test procedures are available; test personnel 
are trained in test operations; test procedures have been “dry-run”. 

Sample items reviewed. Software and hardware test plans and procedures; software unit test 
cases, procedures, and results; test schedules, certifications for test personnel. 

Likely exit criteria. Test plans and procedures completed. 

Definition of success. Test and safety engineers have certified that preparations are complete 
and formal test initiation is authorized. 

Production Readiness Review (PRR) 

Purpose. To determine readiness to begin production; ensure logistics support 
documentation and resources are in place or will be available to support deployment. For 
single use systems, this may be replaced by an operational readiness review, leading to a 
decision to deploy the system in the operational environment. 

Likely entry criteria. All significant production engineering problems encountered during 
development are resolved; production plans developed; design and drawings certified. 



Sample items reviewed. Production design and processes; parts lists. 

Likely exit criteria. Production processes and methods in place. 

Definition of success. Decision to begin production. 

Project Manager Tailoring Approach 

For any project the project manager must identify the key stakeholders, and for each be able 
to address areas of greatest interest. While this is generally a good practice to improve 
communication and avoid surprises, the focus here is to agree to the tailoring of reviews, 
with the stakeholders understanding and acceptance of the benefits and associated risks with 
the project manager’s decision. 

For our purposes the project manager is “the person responsible for planning, directing, 
controlling, structuring, and motivating the project, and is responsible for satisfying the 
customer” as defined in (CMMI-SE/SW/IPPD 2000). 

Stakeholders. We use the definition of “stakeholder” from (CMMI-SE/SW/IPPD 2000): “A 
stakeholder is a group or individual that is affected by or in some way accountable for the 
outcome of an undertaking”. For the purposes of this paper, we consider the following six 
stakeholders associated with most projects: developers; customers; vendors and suppliers; 
end users; maintainers; and funding management 

For some projects, these roles may be performed by the same organization, or even by the 
same person. The roles are distinct, however, in the nature of the issues that are central to the 
performance of each. 

The primary role of each of these stakeholders can be described as follows: 

• Developers: The party (individual, project, organization) responsible for creating a 
fully functioning product that satisfies the stated requirements. 

• Customers: The party (individual, project, or organization) responsible for accepting 
the product or for authorizing payment. 

• Vendors and suppliers: The parties who provide some components) of the overall 
product. 

• End users: Those who will operate the product. May also include the back-end analyst 
working with the system output. 

• Maintainers: Those responsible for keeping the system operational after it has been 
fully developed and is being used operationally. 

• Funding management: Those who provide the funding for the project. 

Key Questions. For each of the stakeholders we now consider their interests in the project. 
We provide a set of general questions fox the project manager to consider in developing an 
in-depth understanding of the primary issues for each stakeholder. 

A. Developers Issues and Considerations 

a. Complexity: Is this a difficult technical problem, or is it a relatively straightforward 
extension of known technology? If a difficult problem, what are the specifics that 
make it difficult? What are potential alternative outcomes, due to the complexity? 

b. Size: Is this a large system/product in terms of cost, numbers of users, volume of data, 
communications bandwidth required? Does the size cause concerns about 
coordination requirements between development and operations? 


c. Maturity: Are the requirements mature and well understood? Are the technologies 
necessary for implementation mature, or untested? Is the primary implementation an 
integration activity or a development activity? 

B. Customers Issues and Considerations 

a. Requirements: Will the system meet the functionality and performance requirements? 

b. Schedule: Will the system be delivered according to the schedule? 

C. Vendors and suppliers Issues and Considerations 

a. Availability: What items are needed for the development? Are they available off-the- 
shelf or will a new design effort be required? 

b. Quantity: Is the required quantity known? 

c. Integration: Is there a requirement for integrating vendor or supplier items? 

d. Past experience: Have the requirements been satisfied in an earlier, similar effort? 

D. End users Issues and Considerations 

a. Integration: Is the product implemented as a stand-alone capability, or is it a part of a 
larger system? What interoperability issues are critical? 

b. Locations: Where will the product be operated? How many places? If many, are they 
similar, or different? How many different operational user stakeholders are there? 

c. Operations: What operational facility, security, training, and operational test and 
evaluation, issues are there? How does this relate to the locations? 

E. Maintainers Issues and Considerations 

a. Logistics: What sparing issues are there? What is the maintenance concept? 

b. Organization: How is the maintenance organized? Who is responsible for support at 
which locations? 

F. Funding management Issues and Considerations 

a. Funding source: Who is paying? Are multiple organizations responsible for parts of 
the life cycle funding? 

b. Funding adequacy: Is the funding sufficient to cover all expected life cycle costs? Are 
funds for development only allocated? Are there funds allocated for management 
resave, or are contingency funds available? 

c. Funding oversight: What financial and funding approvals are necessary? What 
reporting is required? How are changes in funding or funding requirements approved? 

Three scenarios 

This section demonstrates the approach to tailoring of reviews for three scenarios. For each 
the situation is described, the stakeholders and relevant issues identified, and the stakeholder 
interests addressed. The result is the suggested set of tailored reviews, at the appropriate level 
of detail that the project manager should conduct. 

I. Development of a Quick Reaction Capability (QRC) 

The U S. Army has defined a mission-critical requirement. A major, 3-day joint exercise has 
been in planning for over six months and is to include participants from several units. Now, 
just two weeks from the scheduled start, an additional unit has been added. However, the 
radio used by this unit is not operable with the radio to be used by the forces for tactical 
communications during the exercise. 


The change, which is technically simple, is to add a software patch to the new unit’s 
radios to accommodate the waveform for the exercise. The overriding consideration for this 
effort is the aggressive schedule that severely compresses the entire SE lifecycle. 

A. Identify the stakeholders. The project manager needs to first identify the key 
stakeholders to focus attention of the most important aspect. The end user is die primary 
stakeholder. Since the radio is already fielded changes must be made without impact to 
the current operational conops. A second stakeholder is the developer as the overall effort 
is greatly impacted by the aggressive schedule. No other stakeholders are significantly 
impacted in this scenario. 

B. Define die relevant issues. The key issue is the schedule. The project manager must 
consider these issues: 

a. What will the impact be if the schedule is not met? 

b. Is the schedule well defined and understood? Is the schedule appropriately 
controlled? 

c. Can the shortened schedule be satisfied with acceptable risk to technical satisfaction? 

d. Are other aspects at risk, such as testing, training, and maintenance? 

Satisfaction of the mission -critical requirement is the primary consideration. However, as 
will be seen, the technical reviews can be tailored to reduce emphasis cm testing, training, 
maintenance, and other issues to meet the shortened development cycle. 

C. Answer the questions. The project manager, having identified the key stakeholders, is 
now able to address the issues and considerations with the critical schedule. 

Issues and considerations of end users: 

1. Integration: This QRC is a software-only enhancement to the existing hardware. All 
integration and interoperability issues are as previously addressed. 

2. Locations: The radios will all be used in the same operational environment. 

3. Operations: No change to facility, security and logistics support issues. No additional 
training is required. 

Issues and considerations of the developers: 

1 . Complexity: This is a simple enhancement of same hardware and software to process 
an additional signal type. 

2. Size: There is no change in terms of numbers of users, volume of data, and 
communications bandwidth required. 

3. Maturity: The change for this QRC is a simple addition to previously achieved 
capability. 

D. Establish tailored reviews. The project manager, with knowledge and agreement of 
stakeholders, now determines what reviews to conduct, and at what level of detail, and 
works to ensure the information needed to successfully complete those reviews are 
obtained. 

System Requirements Review (SRRI 

The dominant issues are that the specific requirement must be met, and the fielding of the 
capability is urgent. So the SRR is very streamlined - both because the requirements set is 
small and focused, and to support schedule criticality. Functional analysis and requirements 
allocation is completed, but other aspects are not needed, such as conducting trade studies or 
a life cycle cost analysis, or developing a configuration management plan. 


System Design Review (SDR) 

This review is not conducted. The design of the fielded system is not being changed to 
incorporate the new requirements. Key documents, such as the system specification, software 
requirements specification, and interface requirements specification will be updated and 
approved in this timeframe, but not as part of an SDR. 

Preliminary Design Review fPDR) 

This review is not conducted. The design of the fielded system is not being changed. 

Critical Design Review (CDR) 

A shortened, focused CDR is necessary to ensure the updated functional baseline satisfies the 
new requirement Additionally, revisions to key documents will have to be approved, 
including the hardware product specifications and software detailed design. 

Test Readiness Review fTRR) 

This review is conducted but is streamlined. Since tins is an enhancement to a current 
operational system testing is streamlined. A subset of already existing test procedures is 
executed, with focus on new functionality and new and changed interfaces. 

Production Readiness Review (PRR) 

This review will be conducted to serve as a final gate to ensure all aspects have been 
addressed. However, it will be streamlined in appreciation of the short schedule, and because 
production processes and methods are already in place. 

II. A Mid-Sized Project Using Spiral Development 

A mid-sized investment management firm, with offices in twelve U S. cities, needs to 
develop a proprietary system for managing their customers’ accounts, in conjunction with 
several types of investment vehicles the company recommends. The system is intended to 
enhance the information the firm can provide to its clients, but must ensure full enforcement 
of complex laws and regulations regarding insider trading. 

The system can use commercially available products, but will also incorporate significant 
development. The approach chosen - due to the rapidly changing available technology, and 
uncertainties in details of requirements, is a spiral development methodology. 

For this paper, we will restrict our discussion to the overall project, and the details of the 
first two spirals. The first spiral is planned to upgrade the hardware and network operating 
system software throughout the company, using commercial products, to establish an 
infrastructure cm which the remaining system functionality can be implemented. Since the 
current systems are similar, this spiral is defined as a two month design effort, followed by a 
four month implementation at the twelve locations. 

The second spiral entails significant upgrades to functionality, to include both custom 
code and negotiated enhancements to some commercial software products. This spiral is 
scheduled for implementation at two of the locations, to allow a significant operational 
testing and shakeout before installation in all locations in later spirals. The second spiral is 
planned as a nine month effort. 

A. Identify the stakeholders. The project manager needs to identify stakeholders for the 


project as a whole, and for each spiral development activity. Customers (in this case the 
operations management at die twelve sites) and funding management (the chief financial 
officer (CFO) and die chief operating officer (COO)) are interested in the overall health 
of the project, and whether the intended ultimate objectives are being met. They are also 
critically concerned with the overall project cost, and the return on investment. 

For spiral 1, the developers and maintainers are the primary stakeholders. End users have 
some interest and involvement, but will not see much change in their day-to-day 
operation. For spiral 2, the end users and vendors are heavily involved, since the 
functionality of their core products is being changed. 

B. Define the relevant issues. The key issues for the overall project include a significant 
complexity of integration of multiple vendors’ products, with the attendant 
interoperability concerns. Cost and cost control are a major concern of the corporate 
senior management, and the issue of the return on investment demands a quick delivery 
of useful products from the early spiral development activities. 

The key issues in spiral 1 are the timing of the upgrade at all the locations, and the 
training of the system administration staff to support the operation and maintenance of 
the new system. The key issues in spiral 2 are the complexity of the development 
requirements, and the availability of the vendor’s software on the negotiated schedule. 

C. Answer the questions. The project manager, having identified the key stakeholders, is 
now able to address the issues and considerations that are most important to the success 
of the project. For this scenario the questions must be addressed for the project as a 
whole, and for each of the spirals. 

Issues and considerations of developers (primarily spiral 1 and 2): 

1 . Complexity: For spiral 1 the complexity is low, for spiral 2 it is high. 

2. Size: The cost of spiral 1 is significant, because it entails an upgrade of the entire 
company’s computing network infrastructure. Cost of spiral 2 is moderate. 

3. Maturity: For spiral 1 all products being used are in general use. For spiral 2 the 
vendor’s products require significant enhancement. 

Issues and considerations of customers (primarfly overall project): 

1. Requirements: The ate operations managers or their designated technical 
representatives will evaluate the system functional and performance test results to 
ensure satisfaction of requirements. 

2. Schedule: The site operations managers or their designated technical representatives 
will establish and monitor the system delivery schedule to their sites, for both 
individual spirals and the overall project. 

Issues and considerations of vendors and suppliers (spiral 2 only): 

1 . Availability: A new design effort will be required. 

2. Quantity: The required quantity is known. 

3. Integration: A critical issue is integrating the vendor or supplier item into the system, 
especially if the vendor’s schedule slips. 

Issues and considerations of end users (spiral 2 only): 

1. Integration: Interoperability of the upgraded product with the software being 
developed is essential to the successful operation of the system. 

2. Locations: To minimize risk, this spiral will deliver to only two similar locations. 



3. Operations: The critical concerns are training, and operational test and evaluation. 

Issues and considerations of maintainers (spirals 1 and 2): 

1 . Logistics: The initial maintenance concept is for the vendor to support any hardware 
maintenance, and the corporate systems administrators to perform software 
maintenance, for both spirals. 

2. Organization: The organization is in place for both spirals. 

Issues and considerations of funding management (primarily overall project): 

1 . Funding source: Funding is defined in the project budget. 

2. Funding adequacy: The initial budget is established and in place; expenditures against 
plan need to be carefully tracked. 

3. Funding oversight: The corporate accounting will handle most of the needs, but 
formal reviews are needed at least once per year. 

D. Establish tailored reviews. For this example, reviews at two different levels are required 
to satisfy the needs of all the stakeholders. Developers, vendors and suppliers, end users, 
and maintainers need detailed technical reviews during each spiral, tailored to the specific 
characteristics of each. For each spiral, the project manager needs to identify the key 
stakeholders, and establish the appropriate reviews as part of the planning for the spiral. 
Customers and financial management are more concerned with a periodic update on the 
status of the project as a whole, including funding status, technology trends, 
implementation summary, and an update to the project plan. We will describe for this 
scenario die reviews that are defined for the overall project, and for the first two spirals. 

System Requirements Review (SRR) (overall project and spiral 1) 

A project level SRR in the first few months of the project, including representation from the 
developer, vendors, and end users, should set the overall project long-term objectives and 
expectations. This review will also address SDR issues and concerns. 

For spiral 1, the SRR is the most important review, to ensure that the requirements and 
training are in place when the new systems are delivered. This will be held two to three 
weeks after the start of the spiral. The SDR issues of design will be covered in conjunction 
with this SRR style review, because the design is not complicated. 

System Design Review (SDR) (spiral 2) 

The key technical design issues are bring addressed in spiral 2, so this will be a significant 
review. It will be held six to eight weeks after the start of the spiral, to allow for significant 
analysis of alternatives, and presentation of recommendations at the review. 

Preliminary Design Review (PDR) (overall project) 

A PDR style of project level review will be useful for the customer and funding management 
stakeholders, after one or a few spirals have been completed. This review will focus on the 
current status to ensure that the project is headed in the right direction. 

Critical Design Review (CDR) (overall project and spiral 2) 

The overall project can benefit from the formality of a major review somewhere in the 
middle of the development. This will have much of the flavor of a CDR, with adjustments in 
detailed content to reflect the actual delivery and operation of significant capabilities. This 
review is a cost and schedule checkpoint, and would emphasize the plans for completing the 
development project. 


A CDR is scheduled for three to four months after the start of spiral 2, with the schedule to 
be adjusted at the time of the SDR. This review is relatively short (one day), but essential. 
Test Readiness Review (TRR) (all) 

On the project level, this review will be scheduled later than the completion of the second 
spiral, after the system functionality has been migrated to most of the twelve locations, in 
preparation for a multiple site exercise of the system. 

For spiral 1, this review will be used to evaluate the installation of the system at the twelve 
individual sites, prior to die full test of the multiple-site infrastructure. 

For spiral 2, this review will be a formal evaluation of the installation of the system at the 
two sites involved in this spiral. 

Production Readiness Review fPRR) (all) 

For the entire project, this review will be scheduled about two months prior to the planned 
completion, to allow a final formal evaluation of the satisfaction of the intended functional 
and performance requirements. 

This review will close out spiral 1, if successful, by ensuring that the system infrastructure is 
ready to support the company’s operations. 

This review will close out spiral 2, if successful, by ensuring that the development software 
and the vendor’s contracted upgrades interoperate as designed. 

III. Development of a new Earth Science Research Satellite 

The President of the United States, alarmed by the October 2003 wildfires in California, has 
called on NASA to deliver a new satellite designed specifically to study the Santa Ana winds. 
Measuring winds from space is not a new concept, but this satellite is expected to provide 
data with ten times the resolution of existing satellite data. The satellite already has a 
projected launch date of July 4, 2007 - a date obviously selected for its patriotic significance. 

As seen here, the overriding consideration for this effort is the high visibility and a firm, 
but not necessarily aggressive schedule. 

A. Identify the stakeholders. The project manager needs to identify the key stakeholders, 
which are the President who spearheads this initiative and Congress, which controls 
project funding and is subject to wild perturbations. Stakeholders who will participate 
more directly in the review process include NASA’s Associate Administrator for Earth 
Sciences and his staff, meteorologists, and safety and rescue organizations that will 
benefit from this satellite’s capabilities. The developer is crucial to ensuring that the 
mission goals are feasible. The operations and maintenance personnel are less critical, as 
satellites such as this have been operated before and present minimal new challenges. 

B. Define the relevant issues. The key issue is the technology. The project manager must 
consider these issues: 

a. Can the technology goals be met? 

b. What are the specifics that make this a difficult problem? 

c. Are the requirements mature and well understood and defensible? 

d. What will the impact be if the schedule is not met? 

e. Is the schedule appropriately controlled, with sufficient slack? 

The project manager must consider the impact of these issues on the political 


stakeholders and demonstrate that the satellite, while politically motivated, is technically 
warranted and economically justified. Every review must reinforce that message. The 
technical reviews can be tailored to emphasize this message and reduce emphasis on the 
more routine aspects, including operations, training, and maintenance. 

C. Answer die questions. The project manager, having identified the key stakeholders, is 
now able to address die issues and considerations with the technical complexity. 

Issues and considerations of the President/Congress: 

1 . Funding source: Not an issue at this time. Funds have been specifically earmarked. 

2. Funding adequacy: Also not an issue as ample funding has been provided. 

3. Funding oversight: A significant issue. Extensive reporting required including 
special presentations outside the normal review process. Project Manager must tailor 
the design reviews to political and scientific stakeholders to ensure that the funding 
remains adequate. 

Issues and considerations of the developers: 

1. Complexity: The complexity is determined to be in the new instrument. The rest of 
the project is less complex. 

2. Size: die satellite is not large compared to other satellites currently in development. 

3. Maturity: The requirements are well understood. There is a single untested 

technology in the new instrument. The rest of the project is largely integration. 

D. Establish tailored reviews. The project manager, having identified the developers and 
Congress/political leaders as die key stakeholders and their critical needs and interests in 
the project, now determines what reviews to conduct, and at what level of detail. 

System Requirements Review (SRR1 

The dominant issue is the main requirement of the mission, but there are many other derived 
requirements - what orbit the satellite will be in, what launch vehicle, and what 
communications system. The review will include major design alternatives considered, the 
relative risk for each and the reasons for the approach chosen. The SRR will be large and 
formal, reviewing the draft system specification, functional analyses and preliminary 
requirements analyses. There will be one segment of the review that is a very high level 
overview, primarily intended for Headquarters management. 

System Design Review (SDR) 

This review is also a formal affair. It is expected that any major issues have surfaced in one 
of several dry runs and worked already so that there are not major surprises during the 
review. The design may be based considerably on the design of a previous mission with 
deviations from that mission closely scrutinized. Key documents, such as the system 
specification, software requirements specification, and interface requirements specification 
will be updated and approved before this review. 

Preliminary Design Review (PDRl 

Due to the size of this project and the visibility, a series of PDRs will be held for each 
subsystem rather than one review. Although a detailed design is not required systems 
engineering, resource allocations and design analyses are required to demonstrate compliance 
with requirements. The design and interfaces are presented using, for example, block 
diagrams, signal flow diagrams, schematics, and logic diagrams. Estimates of weight, power. 


volume and die basis of estimates of these parameters are required. The software design, 
structure, logic flow diagrams, design language and development systems are specified. 

Critical Design Review (CDR) 

This project warrants a formal two or three day CDR to present the final design. Due to the 
high visibility, several dry runs will be conducted using the same products initially presented 
at the PDR. Final weight, power and volume estimates, software requirements, and system 
performance estimates are presented. In addition, the review should include engineering 
model/breadboard test results and design margins, reliability analyses results, final 
implementation plans, completed design analyses, launch vehicle interfaces and ground 
operations. 

Test Readiness Review (TRR) 

This review is somewhat less extensive since this project is similar to a previous satellite. 
The purpose is to evaluate the planned test/calibration program and test flow to assure that it 
meets the project needs and to assure that a proper baseline of performance of the item to be 
tested has been established. 

Production Readiness Review (PRR) 

At the PRR the overall readiness of the mission will be assessed. This review is scheduled 
for three days before the scheduled launch date. It is a review of the total system to support 
the flight objectives of the mission; however, it is expected to be largely ceremonial in this 
case, with a large number of dignitaries present Closure of this review and any actions 
generated indicates that the mission is ready for launch. 

Principal Benefits of Tailoring Approach 

The tailoring of SE processes and products to best support the project application and 
environment is a fundamental project manager function. This paper provided the project 
manager guidance on tailoring of major technical reviews based on an understanding of 
project characteristics and the interests and concerns of the key stakeholders. We believe 
that this approach offers benefits throughout the project lifecycle. 

The project manager, even before formal project initiation, identifies the key 
stakeholders, and their critical needs and interests. This becomes the basis for effective 
communications throughout the project and enables the project manager to take steps to 
ensure appropriate incorporation of reasonable means to address the concerns of each. 

Additionally, the project manager should attempt to determine whether key stakeholders 
have conflicting objectives, and balance those that may be difficult (or even impossible) to 
meet in their entirety. For example, while the developers may desire reducing the scope of 
reviews, the customers may be concerned that the reviews will not provide sufficient insight 
into the project. 

And as changes invariably occur during the project lifecycle, the project manager uses the 
understanding of key considerations of the stakeholders to ensure the most important issues 
and interests are being addressed, keep stakeholders abreast of changes, and to manage 
expectations. By carefully monitoring the influences and impacts on stakeholder 
considerations the project manager will be better positioned to lead the project to success. 
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